Internet Standards/CD1.mdf/winsock/hacker/93-11/[e-mail]_Wed Nov 17 03:56:01 1993.msg

Internet Message Format | 1993-11-29 | 8KB

Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA29737; Tue, 16 Nov 1993 16:49:13 -0500
Received: by usage.csd.unsw.OZ.AU id AA13614
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 17 Nov 1993 08:47:02 +1100
Received: by atlas (4.1/1.35)
    id AA06368; Wed, 17 Nov 93 08:56:02 EST
Message-Id: <9311162156.AA06368@atlas>
From: [e-mail]
Date: Wed, 17 Nov 1993 08:56:01 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail],
        Multiple recipients of list <[e-mail]>
Subject: Re: Timeouts on WSAAsyncSelect FD_READ

Thus expounded David Watt on Nov 10, 7:35pm:
/--------------------
|By the way, I have a question about setting FD_CONNECT on UDP sockets.
|Now granted, UDP sockets don't make connections.  But if you set
|FD_CONNECT, and then use the connect() call on a UDP socket to set
|the destination address for subsequent send() calls, shouldn't the
|socket window receive an FD_CONNECT message?  The specification is,
|to my mind, ambiguous on the subject: in the description of the
|connect() function, it says:
|
|"2. If your application is using the message-based WSAAsyncSelect() to indicate interest in connection events, then your application will receive an FD_CONNECT message when the connect operation is complete."
|
|How does this apply to UDP sockets?  In the NT implementation, which is
|the only one I've tested this on, UDP sockets never receive FD_CONNECT
|messages, which is a mild annoyance when trying to implement a protocol
|simulateously in TCP and UDP.

This is actually a thorny problem. I was going to reply "of course a connect()
on a UDP socket should have a FD_CONNECT message sent"... but ...

    For TCP sockets,
calling WSAAsyncSelect() puts the socket in non-blocking mode automaticaly.
Since connect() for TCP sockets could take arbitrary time, it then returns
SOCKET ERROR / WSAEWOULDBLOCK, and you get the FD_CONNECT message some time
later. For UDP sockets, though, connect() is never a blocking call - it proceedsimmediately, and will not return a WSAEWOULDBLOCK error.
    I guess they have implemented it so that you only get an asynchronous
message (FD_CONNECT) if the related connect() attempt failed with
WSAEWOULDBLOCK. An interesting experiment would be to try to connect() to
a local socket on the same machine - say through address 127.0.0.1. using TCP.
and seeing if that returns a WSAEWOULDBLCOK error (although I guess there's
no reason why not) and if not, whether you still get a FD_CONNECT message.

    Check if your UDP connect is returning SOCKET_ERROR/WSAEWOULDBLOCK.
If so, you definitely should get an FD_CONNECT message soon after. If the
UDP connect() succeeds, there is no need to post a FD_CONNECT message - you
already know its connected.


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Wed Nov 17 04:00:09 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA29835; Tue, 16 Nov 1993 16:50:19 -0500
Received: by usage.csd.unsw.OZ.AU id AA13723
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Wed, 17 Nov 1993 08:50:15 +1100
Received: by atlas (4.1/1.35)
    id AA06438; Wed, 17 Nov 93 09:00:10 EST
Message-Id: <9311162200.AA06438@atlas>
From: [e-mail]
Date: Wed, 17 Nov 1993 09:00:09 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail], Multiple recipients of list <[e-mail]>
Subject: Re: recv() after FD_CLOSE

Thus expounded Bob Quinn on Nov 10,11:29pm:
/--------------------
|>  >BTW, you might want to select on FD_READ and FD_CLOSE; when you get an
|>  >FD_CLOSE, be sure to read until it no longer makes sense to do so.
|
|Since FD_CLOSE is posted when a connection is closed gracefully
|or ungracefully (i.e. when TCP <FIN> or <RST> is received).  And
|since a host cannot possibly send data after sending a TCP <FIN>
|or <RST>.  It doesn't ever make sense to read after getting an
|FD_CLOSE.  Why should you?

Oh dear - FD_CLOSE wars again. I beleive the reason is that some stacks post
FD_CLOSE as soon as the <FIN> arrives - whether there is still more data
to be read in the incoming buffer or not. So getting an FD_CLOSE is no
guarantee there is not still more data to read - you must keep reading after
FD_CLOSE until recv() returns 0, and then you have truly hit the end of
the data stream.

| Bob Quinn                                             [e-mail]
| FTP Software, Inc.                                No. Andover, MA

So when _exactly_ does FTP's WINSOCK post the FD_CLOSE message ? :-)


--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Mon Nov 22 06:11:44 1993
Received: from usage.csd.unsw.OZ.AU by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AB18211; Sun, 21 Nov 1993 19:26:00 -0500
Received: by usage.csd.unsw.OZ.AU id AA22284
  (5.65c/IDA-1.4.4 for winsock-hackers%sunsite.unc.edu); Mon, 22 Nov 1993 11:25:29 +1100
Received: by atlas (4.1/1.35)
    id AA19089; Mon, 22 Nov 93 11:11:44 EST
Message-Id: <9311220011.AA19089@atlas>
From: [e-mail]
Date: Mon, 22 Nov 1993 11:11:44 -0500
X-Mailer: Mail User's Shell (7.2.2 4/12/91)
To: [e-mail]
Subject: non-blocking lingering close

I've been looking at using non-blocking calls, but emulating the behaviour
of a blocking close, and have determined there is no real way to
do so given the 1.1 interface spec. A "blocking graceful close" is when
closesocket is called on a socket with a non-zero linger time, and it
should block, waiting for all the buffered outgoing data to be sent and
acknowledged before returning.

    The problem is that there is currently no way to determine if there
is still buffered data waiting to be written. Ioctlsocket() has the FIONREAD
parameter, to return an indication of data waiting to be read, but there is
no corresponding FIONWRITE parameter to determine if buffered data is still
waiting to be sent to the remote host, or has not been acknowledged.

    What are people's thoughts on emulating a lingering close, and whether
a new ioctlsocket() parameter could be defined for version 2.0.



--
Paul Brooks              |[e-mail]       |Emerging Standard:
TurboSoft Pty Ltd        |[e-mail]|  one that has not yet
579 Harris St., Ultimo   |                         |  been superseded.
Sydney Australia 2007    |ph: [phone]       |
From [e-mail] Fri Nov 22 01:38:20 1993
Received: from dub-img-1.compuserve.com by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.06) with SMTP
          id AA23911; Mon, 22 Nov 1993 06:41:12 -0500
Received: from localhost by dub-img-1.compuserve.com (8.6.4/5.930129sam)
    id GAA20483; Mon, 22 Nov 1993 06:41:11 -0500
Date: 22 Nov 93 06:38:20 EST
From: Franck LEFEVRE <[e-mail]>
To: "INTERNET:winsock-hackers" <[e-mail]>
Cc: "INTERNET:winsock-users@s" <[e-mail]>,
        "INTERNET:winsock@sunsite" <[e-mail]>
Subject: WSDIR932
Message-Id: <[e-mail]>

WSDIR the WinSock directory

The WSDIR932 of November 17th, 1993 is now available.

The first goal of WSDIR is to provide a regularly-updated directory of  WinSock
applications, implementations and development tools. It contains only, and will
always only contain, data sheets that have been  directly filled by poeple
responsible for the product submitted.

There are 3 official ways to get a copy of WSDIR :

    1) K1's BBS (France)  (33) 33.39.22.13       Files Area :  TCP/IP
    2) CompuServe             Forum : MSNETWORKS
    3) Anonymous FTP to ftp.demon.co.uk:/pub/ibmpc/winsock  (thanks,  Steve)



Franck LEFEVRE
K1 Informatique
[e-mail]